When a patient seeks healthcare services from a healthcare provider, the provider may request information from a payer (e.g., insurance company) to determine if the patient is eligible to receive benefits for healthcare services; and if the patient is eligible, the provider may request other benefit and eligibility information such as benefit amounts, co-insurance, co-pays, deductibles, exclusions, and limitations related to a specific procedure. The request for information may be sent as an eligibility request, for example, a 270 request or transaction. A payer may communicate eligibility benefit information associated with a subscriber or dependent in a response, for example, a 271 response or reply.
The eligibility request and response may be required to meet processing standards. For example, eligibility transactions may be sent in an X12 syntax format and may be coded and structured according to standards established by the Secretary of Health and Human Services (HHS) as required by the Health Insurance Portability and Accountability Act of 1996 (HIPAA). As is known in the art, HIPAA includes provisions for administrative simplification and support electronic exchange of administrative and financial healthcare transactions primarily between healthcare providers and plans. As should be appreciated, embodiments may be utilized with other formats, structures, and syntaxes according to changes in healthcare laws. For example, a 270 eligibility request may be replaced by an eligibility request of another format and utilizing an alternate syntax. A 271 response may be replaced by an eligibility response of another format and utilizing an alternate syntax.
Healthcare eligibility transaction sets may be designed to satisfy needs of a simple eligibility status inquiry (e.g., is a subscriber/dependent eligible?). When a request is made for more complex information (e.g., benefit amounts, co-insurance, co-pays, deductibles, exclusions, and limitations related to a specific procedure), the content of eligibility responses may vary depending on a level of data made available by an information source.
Implementation guides may be provided so that health plans, providers, clearinghouses, and software vendors may be able to ready their information systems and applications software for compliance with the standards; however, some transmission formats may not be specific enough to provide enough structure for an eligibility response to be able to guarantee that, for example, a healthcare provider will be able to find a specific piece of information in a specific place. While some consistent usage of standards, including loops, segments, data elements, etc. across all guides is used to support standardization, ambiguities and variations may arise in eligibility responses due to an imprecise nature of an implementation guide, for example, the X12 implementation guides adopted by HIPAA. According to one example, the X12 format may require an input of a deductible amount in a specific eligibility benefit segment of a 271 response; however, the format may not require for the input to be a specific input type (e.g., dollar amount vs. percentage, etc.). A healthcare provider may receive a 271 response from one payer with a deductible amount in a dollar format and a 271 response from another payer with a deductible amount in a percentage format. As can be appreciated, receiving 271 responses in inconsistent formats can be inefficient, frustrating, and may lead to errors.
Additionally, service codes used in an eligibility response may be inexact and limited. For example, only simple provider/payer/patient relationships may be coded in compliance with HIPAA, causing an overlap between place of service codes and service type codes. Payers may use a degree of latitude in selecting which HIPAA code values to use. Minimal restrictions within implementation guides may allow payers to use various code values when coding the same information. Accordingly, an eligibility response may be standards-compliant yet still require extensive analysis by a healthcare provider to understand the actual benefits. While a historical assumption is that a 271 response may be processed as a human readable response, not as a machinable transaction whose data content may be utilized to drive software processes downstream, current systems do not provide for highly consistent responses that match formatting of other payers' 271 responses.
It is with respect to these and other considerations that the present invention has been made.